Alpha Cloud - Alpha Anywhere Developer's Guide
Migrating Existing Applications to Alpha Cloud
Overview
Database Hosting
File Storage
Code Changes
Third Party Software
Overview
Deploying an application to Alpha Cloud that was previously running on the Alpha Anywhere Application server or Alpha Anywhere Application Server for IIS typically requires few changes. The most significant considerations tend to be conceptual. This is because Alpha Cloud manages the infrastructure for you.
Alpha Cloud applications are automatically deployed to multiple servers (at least two) behind a load balancer. These servers may be stopped and replaced at any time to apply maintenance updates or replace faulty hardware. As load increases, new servers may be started to meet growing demand. This means that you no longer have direct access to a server. Instead, you use Alpha Cloud dialogs to define "what" you want to configure, and Alpha Cloud makes it happen for you.
Because web sites are deployed using Alpha Anywhere Application Server for IIS, there are multiple processes running at a time. These processes are automatically managed by Microsoft IIS.
If you have made use of any of the older features related to security, you may have to modernize parts of your application to be compatible with Alpha Anywhere Application Server for IIS. This is because Alpha Cloud deployed applications run on Alpha Anywhere Application Server for IIS. The good news is that the changes required are backward compatible and can be made while your application is still running on Alpha Anywhere Application Server or Alpha Anywhere Application Server for IIS.
In the following sections we will look at four areas to consider in moving your application to Alpha Cloud.
Database Hosting
While Alpha Cloud includes test database support for MariaDB, PostgreSQL, or SQL Server, Alpha Cloud does not currently host production databases. This is a feature under consideration, but we believe there are some very good existing vendor offered services and until we can assure comparable quality, performance and data protection we recommend that you use an existing service. As a result, your database must be hosted somewhere that can be accessed by your application running on Alpha Cloud.
There are essentially two options for hosting your production database:
- Subscribe to a Database-as-a-Service (DBaaS) Provider - We recommend Amazon RDS (Relational Database Services) because your database can be deployed in the same geographic region as your Alpha Anywhere application. There are, however equivalent offerings from Google (Google Cloud Platform) and Microsoft (Azure) as well as a number of database specific providers.
- Open your firewall to Alpha Cloud - This option requires you to open the firewall your database is behind to up to three IP addresses from which Alpha Cloud will attempt to connect to your database.
Regardless of which option you choose, you will configure access to your database based on IP address and you will want to configure your server for secure access.
Note: You should always secure connections to your database using TLS(SSL) or SSH.
For more information on securing database connections see:
Connecting Securely with TLS and SSL
Connecting Securely with SSH
File Storage
Because servers may come and go at any time, it is not appropriate to store writeable files on servers at runtime. You can, of course, publish read-only files from your web project and they will be copied to the web site when servers are started or updated.
Cloud deployments typically use a service referred to as Cloud Storage. These services let you store and retrieve objects using a path similar to a directory structure. The access to these objects is done over the internet with a secure connection.
Alpha Anywhere's A5Storage classes have built-in support for Amazon S3 (Simple Storage Service) and Microsoft Azure as well as local and network files. These storage classes use connection strings similar to database connection strings. This makes it relatively easy to configure the same application for local deployment and select an alternate connection string for Alpha Cloud deployment.
You can store any file that you would normally store on the local file system on Amazon S3, using your own Amazon account.
You can also save large objects to storage for the current session from Xbasic by using Session Storage functions implemented on the Context.Session global object.
See Context.Session Object for more on these functions.
When deploying to Alpha Cloud the stored objects are cleaned up automatically.
Note: The you must set the configuration for session storage manually in your server settings when deploying to Alpha Anywhere Application Server and in the publish profile for Alpha Anywhere Application Server for IIS on-premises,
but the behavior is the same, and your application will work without changes both locally and on Alpha Cloud.
Note: You are not required to use cloud storage. You also have the option of hosting a file server of your own using a variant of security FTP (SFTP or FTPS). Both of these are supported in Alpha Anywhere and Alpha Cloud.
For more information on storage classes and secure file transfer see:
A5Storage Namespace
INET::FTP Class
INET::SFTP Class
Code Changes
There are three common areas of your application that you may need to attend to:
- We have already discussed cloud storage, and the need to store uploaded files in a more permanent place than the server running your application. This means that you can no longer assume in your code that files you copied to the server are going to be there. In fact, you do not have write access to the file system other than temporary storage.
-
If you need to store a file for part or all of the session lifetime, you can use the Context.Session object methods SaveDataAsFile(), GetDataFromFile(), SaveFileToSessionFile(), or SaveSessionFileToFile()
to save and retrieve data from session storage. Since session storage is managed for you automatically in Alpha Cloud, this is fairly simple easy to do.
Call Context.Session.FormatFileDataURL() to get a URL for a session file that you can request directly from browser code.
There are also methods such as DeleteSessionFile() to help you manage the lifecycle as well. -
Alpha Anywhere Application Server for IIS, of course, runs under Microsoft Internet Information Services (IIS) and as a result uses a different mechanism for
authentication and authorization than Alpha Anywhere Application Server. As a result, there are some key differences that may require attention in your code.
Some of these changes are required for on-premises Alpha Anywhere Application Server for IIS, and others are more strictly enforced on Alpha Cloud.
- The schema for the database containing users and roles is determined by Membership and Role providers and this schema is fixed.
You cannot alter the schema or manipulate the data tables from outside of the providers.
These providers are pluggable components that implement a set of functions defined by Microsoft.
When Alpha Anywhere Application Server for IIS was introduced, a new object was added to the environment to make accessing the classic security functions as well as IIS consistent. The object is part of the Context object and is addressed as Context.Security.
You can find more information about this object at Context.Security Object
Note: Many of the classic security functions are automatically mapped to Context.Security methods when running under Alpha Anywhere Application Server for IIS. While it is recommended that you update your code to use Context.Security references, existing code may work unmodified. - If you have altered the existing security tables to include information specific to your application, you may retain these tables, but the users and roles will no longer be read from them. You will have to manage the tables independently from the Context.Security functions.
- The Guids used as unique keys for users and roles in the classic security system are no longer supported. If you have tables that depend on the Guid values, you will want to create a table (or add a column) mapping a user name to a Guid or you can also update your tables to use the user name directly.
- Again, if you have been using SQL queries to access users and roles directly, you will need to change this code to use the Context.Security functions instead.
- The schema for the database containing users and roles is determined by Membership and Role providers and this schema is fixed.
You cannot alter the schema or manipulate the data tables from outside of the providers.
These providers are pluggable components that implement a set of functions defined by Microsoft.
Third Party Software
While you do not have access to servers to install software as an administrator, there are some options for running third-party software on Alpha Cloud.
- If your application is a .Net assembly, you can simply copy that assembly into the "bin" folder under your web project and it will be published to Alpha Cloud and your web site automatically. Note: You must still register the assembly as you would on premises. Since the assembly is in the "bin" folder under your web project, you will want to address the assembly using the ApplicationRoot property of the Context.Request object.
- Other executables can also be included in the bin folder, especially if they can be run directly without an installer.
- While you can run an installer as part of a web request, as long as the installer can install for the current user only, this may not be optimal because you the time taken to run the installer may be longer than the request should run, and you would want to make sure that the installer runs exactly once per server (only installs if the application is not installed).
Note: Keep in mind that large applications will slow down your publish and deployment time and add unnecessary complexity to your application. If you can replace the executable with a third-party service, you will likely save some work for yourself and create a better user experience.